[レポート] 上級者向けサーバーレス開発のベストプラクティス #SVS401-R #reinvent

アノテーション テクニカルサポートの川崎です。

本記事は AWS re:Invent 2022 のセッションレポートとなります。

概要

あなたは経験豊富なサーバーレス開発者ですか? 本番環境のワークロードでサーバーレス アーキテクチャを最大限に活用するための役立つガイドが必要ですか? イベント ソースとしてストリームと API のどちらを選択するか、または関数を 1 つにするか複数にするか迷っていますか? このセッションでは、アーキテクチャのベストプラクティス、最適化、便利なチート コードを提供して、安全で大規模かつ高性能なサーバーレス アプリケーションを構築し、実際の顧客シナリオを使ってそのメリットを説明します。

セッション動画

セッション資料

Best practices for advanced serverless developers

セッション情報

SVS401

アジェンダ

• サーバーレスとは？
• イベント状態
• サービスフル サーバーレス
• 素晴らしい Lambda 関数
• Configuration as code (コードとしての構成)
• プロトタイプから本番まで

1 はじめに

私は Julian Wood といいます。 AWS のサーバーレス製品のチームで働いており、 開発者やビルダーを支援して、サーバーレスアプリケーションを構築して実行するベストの方法をお伝えしています。

サーバーレスのベストプラクティスは広範囲で、6つの分野に分類されます。 このセッションでは、より多くの情報とコンテンツを共有するために、いくつかの出発点を提案します。 まず、サーバーレスとは何かという根本的な質問に答えます。サーバーレスは、その下にあるサーバーや技術ではなく、ビジネス価値に焦点を当てたアプリケーションを構築するための考え方です。その利点は、迅速なフィードバックサイクルと低い所有コストです。 サーバーレスは運用モデルとして考えられ、運用タスクを最小限に抑え、管理タスクをアウトソーシングすることが求められます。データやイベントの流れに焦点を当てることができ、サービスは疎結合で分散されています。ただし、トレードオフも考慮する必要があります。

現代のサーバーレスアプリケーションでは、アプリケーション構築プロセス全体が効率的に行われるように、デプロイとインフラストラクチャ、コードツール、インフラストラクチャコードの所有権を開発者やビルダーに移行します。これにより、サーバーレスのベストプラクティスに沿ったアプリケーション開発が可能になります。 サーバーレス戦略を成功させるためには、制約を有効にし、意思決定プロセスをスピードアップし、迅速な開発を実現することが重要です。 セキュリティやプラットフォームのチームは、問題や間違いを見つけ出し、迅速に軌道修正を行うことができます。 プラットフォームを製品と捉えることは、開発者体験を向上させてビジネス成果を向上させる良い考え方です。

2 プラットフォーム チームの有効化 [7:44]

これは、イネーブリング プラットフォーム チームまたはCCAOEがアジリティの加速に集中できるようにすることを意味します。CI/CDパイプラインを改善し、アカウントの防御プロセスを自動化し、サードパーティシステムへの接続も管理できます。さらに、アプリの不正使用を減らすために堅牢なガードレールを作成し、他のサービスを活用したり、アクセス権限を設定したり、他のガバナンスツールを使って適切に保護します。 プラットフォームチームは、中央ネットワーク接続やVPCを管理できるのも役立ちます。そのためには、CDKコンストラクトやサーバーレスパターンなどの構築ブロックを使い、滑走路を提供し、迅速かつ安全に作業ができるようにします。ボトルネックを作らないようにサポートしたり助けることが求められます。 サーバーレスフレームワークの選択において、ベストプラクティスに従い、適切に設計されたフレームワークを選ぶことが重要です。また、ロックインの問題に対して、Gregor Hohpeはメンタルロックインに注目し、変更にかかるコストを削減し、変更が必要になる可能性を減らすことができると提案しています。 イベント駆動型アプリケーションを開発する際に、状態についても考慮する必要があります。同期ワークフローにのみ依存すると、追加のレイテンシーや復旧を複雑にする問題が生じる可能性があるため、遅延を減らし回復力を高める非同期パターンを検討してください。 非同期通信を処理するために利用できる、強力なサーバーレスメッセージングサービスがいくつもあります。例えば、キュー用のSQS、トピック用のSNS、EventBridgesハブ、ルーティング用のイベントバス、ストリーミング用の Kinesis などです。 イベントルーティング用のサービスである EventBridge を用いると、多数のソースからイベントを受信し、イベントバスに流すことが容易になります。このサービスを利用することで、非常に多様な統合パターンが作成できます。 サーバーレスアプリケーションの中心には、"イベント"という言語で考えることが重要です。イベントドリブンアーキテクチャを通じてイベントの流れをメッセージングサービスで管理し、分散システムを構築します。全体として、サーバーレスを考え方として捉え、ビジネス価値に焦点を当てたり、クラウド上の長期的な運用と構築に最適化することが求められます。

3 進化するアーキテクチャ [12:30]

進化するアーキテクチャの話題では、消費者が時が経つにつれて変わる可能性があり、簡単に追加できるイベントを作成して、柔軟な進化的アーキテクチャを構築できることが述べられています。しかし、どのような情報をイベントに入れるべきかという疑問が常に存在します。イベントを充実させるためのアイデアが紹介されており、EventBridgeイベントにはイベントエンベロープと詳細フィールドがあります。また、制御する場合はリソースフィールドをエンベロープに追加することが推奨されています。 詳細フィールドの構造についても言及されており、イベントメタデータを追加すると便利な場合があります。また、境界を超えることでイベントの流れをつなぐのに役立ちます。相関IDやアイテムの効力トークンを追加することも考慮されています。 詳細データの中には、イベント情報自体が配置されます。例として、注文IDとユーザーIDが追加されています。しかし、実際にはいくつかのカップリングが作成されているため、理想的には分離されたシステムが必要です。この例では、ダウンストリームサービスが必要になります。 カップリングを回避する方法として、下流のソースと消費者が必要とするものをデータフィールドに追加することが提案されています。また、バージョンスキーマが必要になる場合もあります。イベント搬送状態転送という便利なパターンが紹介されており、イベント状態がサービスを通過し、ダウンストリームサービスが必要なデータの独自のローカルキャッシュビューを構築できる場所です。 イベントキャリーステートコンソールを使用することで、分散状態の問題に陥ることなく、適切なデカップリングを行うことができます。消費者は時間の経過とともに変化し、作成したイベントを使用して簡単に追加できるようになります。このように進化するアーキテクチャは、柔軟性と拡張性を持つシステムを構築する上で重要な要素となります。

4 実装の詳細を公開する [15:09]

実装の詳細は、注文情報や金額など、他のサービスに漏らしたくない情報がある場合には公開しないほうが良いです。さらに、イベント状態について考える際、非同期呼び出しを使用する場合は、イベントをサーバーレスアプリケーション言語として考えることが重要です。これにより、イベントをより有用なものにすることができます。 その後、サービスフルなサーバーレスアプリケーションについて説明しています。Lambdaを使ったアプリケーションでさまざまな言語を使用できることを知り、独自のものを持ち込むことができます。そして、Lambdaベースのサーバーレスアプリケーションや独自のコードを削除して、直接サービスと通信できるように説明しています。 また、Lambda関数のロジックの量と、複雑さが増すことを検討することが重要です。どのくらいの機能を追加し、コードで実行するかに注意を払うことが必要です。 さらに、サーバーレスアプリケーション間の通信モデルでは、オーケストレーションとコレオグラフィーを効果的に使用することが重要です。 最後に、Step FunctionsやEventBridgeを活用して、アプリケーションのコンポーネントを効果的に管理し、Lambda関数を使用しないことをお勧めしています。 これらの内容をまとめると、実装の詳細を公開しないことや、サービスフルなサーバーレスアプリケーションを構築する方法に重点を置き、複雑さを最小限に抑えることが重要です。また、Step FunctionsやEventBridgeなどのAWSサービスを活用することで、Lambda関数を使用しない効果的なアプリケーション設計を実現できます。それによって、スケーリングや回復力、セキュリティを向上させ、コストを削減できます。

5 Lambda イベント ソース マッピング [22:12]

Lambdaには、さまざまなサービスとの連携を実現する優れたポーリング機能がいくつか用意されています。イベントソースマッピングは、KinesisやDynamoDB、独自のSQSキュー、あるいはセルフホステッドのKafkaを含むKafkaソースからアイテムを読み取るLambdaポーラーリソースです。これには、AWSのサービスではないものも含まれます。Amazon Q for Rabbits や Active MQ も同様です。 ポーリング機能は、これらのソースからメッセージをプルし、オプションでフィルタリングができる非常に便利な機能が組み込まれています。これにより、関数へのトラフィックが減らされ、コードが簡素化され、コストが削減されます。 ポーラーは、レコードを単一のペイロードにバッチ処理し、Lambda関数に送信して処理されます。また、これらのポーラーは、Lambdaサービスの一部として管理されるため、大きな利点があります。独自のコンシューマEC2インスタンスやコンテナを実行してスケーリングし、メッセージを取得するための料金を支払う必要はありません。実際には無料で利用でき、Lambda関数の呼び出しに対してのみコストがかかります。Lambdaが提供する機能以上のことを実現することができます。

6 AWS Lambda 実行環境のライフサイクル [23:11]

それでは、Lambda実行ライフサイクルとその概要について説明します。実際には3つのフェーズが存在し、それらはINIT フェーズ、INVOKE フェーズ、そして SHUTDOWN フェーズです（スライドでは SHUTDOWN フェーズは表示されていません）。 関数の最初の呼び出しリクエストが来ると、Lambda は INIT プロセスの最初の部分を実行します。これにより、関数の設定に基づいて新しい実行環境が最初に作成されます。タイムラインは左から右に進んでいきます。安全な実行環境は、コードを実行するためのマイクロ VM 内の安全で分離されたランタイムです。他の顧客やアカウント、または他のLambda関数とは共有されません。 次に、LambdaはコードとLambdaレイヤー、またはコンテナイメージをダウンロードします。その後、言語ランタイム（例えばJavaやPythonのノード）を初期化します。そして、関数の初期化コードを実行します。これにより、コールドフェーズの初期化開始、初期化段階が完了します。 その後、呼び出しが開始され、実行がイベントを受け取り、ハンドラーコードを実行し、ペイロードとビジネスロジックを受け取ります。呼び出しが完了すると、コールドスタートを実行しなくても実行環境がハンドラーを再度実行できるため、これをウォームスタートと呼びます。 最適化には職務の分離が重要であり、AWSが制御する部分とお客様が制御するコードがあります。さらに、標準の関数構成では、プリハンドラーコードが実行される直前の行に配置されます。ただし、Lambda拡張機能やランタイムの変更などの新機能を使用して、Lambdaの動作の一部を制御することも可能です。そのため、最適化は拡張コードとランタイムの起動方法を制御するタイムラインで少し左にシフトします。 コールドスタートは、Lambdaが新しいイベントを処理するためにスケーリングする場合やプロビジョニングされた同時実行数を設定する場合に発生します。コールドスタートは、関数コードや構成を更新するときにも発生します。これは、新しいデプロイと見なされるためです。また、機能的なライフサイクルも再開します。 コールドスタートは、実際に何を行っているかによって、100ミリ秒未満から数秒まで異なります。一部のコールドスタートは制御できませんが、知っておく価値があります。 コールドスタートの大部分は、実際にはプリハンドラーのINITコードで処理されています。これには、SDKのインポートやソフトウェアライブラリのインポート、シークレットの収集やデータベース接続の確立が含まれます。これらのライブラリと接続を後続のウォーム呼び出しで使用できるため、通常は呼び出しの前にこれを行うことが推奨されます。

7 プリハンドラー INIT コード: ベストプラクティス [26:52]

ここで役立つために何ができるでしょうか。まず、必要がない場合は、モジュールの読み込みをやめ、依存関係の最適化を行います。これにより、実行するコードの量を減らし、デプロイパッケージのサイズを縮小し、コールドスタートを速くすることができます。

限定的な目的に特化したLambda関数をいくつか用意することをおすすめします。その結果、必要のないものはロードしなくなります。 さらに、共有ライブラリの遅延初期化も行うことができます。前述したフリーハンドコードでは、接続を確立するのに適していますが、ウォーム呼び出しのための再接続処理も準備されています。 次に、HTTP接続の場合、SDKでキープアライブを設定し、実行環境の再利用を検討する必要があります。後続の呼び出しのためにデータを保存できることは非常に便利ですが、データの内容に注意してください。後続の呼び出しに適していないシークレットがある場合、呼び出し前にそれらを消去しておくことを忘れずに。 コールドスタートが気になる場合は、コードの追加変更なしで関数のリビジョン同時実行を禁止することができます。これで、パフォーマンスが向上し、Lambda関数の利用も効果的になります。 ですから、これらのベストプラクティスを適用することで、Lambda関数の効率を向上させることが期待できます。

コールドスタートが好ましくない場合は、追加のコード変更なしで関数のリビジョン・コンカレンシーを禁止できます。

8 依存関係を最適化する [28:00]

依存関係の最適化について説明します。SDK全体ではなく、特定のパッケージを含むDynamoDB SDKを使用することで、最大125ミリ秒高速化する可能性があります。 具体的にすることで、コードが小さなパッケージを参照し、コールドスタート中の初期化が高速になります。

また、3メガサイズの Node バージョン3 SDKを使用し、実際に必要なパッケージのみをインポートすることを検討しています。また、TCP接続の再利用がデフォルトでオンになり、接続を高速化できます。ただし、実際には単純な切り替えではなく、いくつかのコード作業が必要です。 遅延初期化をさらに検討しましょう。Pythonの例では、最初に Boto3 モジュールをインポートし、S3クライアントとDynamoDBクライアント用に2つのグローバル変数を設定します。次に、オブジェクトを取得し、初期化されているかどうかを確認し、初期化がまだの場合は行います。これにより、個々の呼び出しの応答性が向上します。 Graviton2プロセスで関数を実行し、最大34%の優れた価格とパフォーマンスを実現できます。解釈されたバイトコード言語は変更なしで実行できますが、コンパイルされた言語はARM64用に再コンパイルする必要があります。また、包含イメージを使用している場合は、ARM専用にビルドする必要があります。 メモリが関数のパワーレバーであり、128メガから最大10ギガまで割り当てることができます。メモリを増やすと、AWSは仮想CPUの数とネットワーク帯域幅を増やします。制約を受けるコードがある場合、メモリを追加することでパフォーマンスが向上し、コストが削減されます。 Lambdaでは、メモリとCPUを集中的に使用するワークロードや、複数のCPUコアを提供するメモリアロケータを備えた任意のLambda関数を実行できます。これにより、CPUに依存するワークロードが向上しますが、マルチスレッドであることが必要です。

9 スマートなリソース割り当て [31:28]

スマートなリソース割り当てでは、メモリ割り当てをビジネスロジックに合わせて、スマートなメモリ割り当てを行うことが重要です。素数計算の関数で128メガから1ギガまでのメモリ構成を試した結果、最速の関数と最遅の関数では10秒以上の差があることが分かりました。しかし、追加のコストは少なく、パフォーマンスが向上します。 最適なメモリ構成を見つけるためには、手動で試行錯誤する必要がありますが、Lambda Power Tunerというオープンソースツールを使用することで、データ駆動型のアプローチでメモリの最適化が可能です。Step Functionsステートマシンを利用し、異なるメモリ構成で関数の複数バージョンを同時に実行してパフォーマンスを測定し、具体的なコストと速度を算出することができます。CI/CDプロセスに組み込むことも可能です。 関数をVPCに接続する必要性については、関数がアクセスする必要があるリソースがVPC内にある場合、Lambdaは簡単に接続できます。ただし、すべての内部AWSトラフィックは暗号化されており、インターネットに公開されていないため、必ずしもVPCに接続して安全性を高める必要はありません。しかし、追加のネットワーク制御や可視性が必要な場合は、VPC機能を利用できます。VPCを使用したい場合でも、Lambdaは適切に機能します。

10 同時実行について [34:23]

同時実行数とは、関数が特定の時間に処理しているリクエスト数のことで、同時処理と考えることができます。関数がLambdaプロセスとそのインスタンスを実行環境として呼び出すとき、イベントを処理し、呼び出された方法に関係なく、一度に1つのイベントだけを処理します。 サービスから引き出されたバッチには、バッチ内に複数のアイテムが含まれるかもしれませんが、それでも1つのイベントと呼び出しと見なされます。一連のリクエストが届くと、Lambdaはコールドスタートを実行し、関数を呼び出します。関数は一度に1つの要求しか処理できないため、実行環境はその間ブロックされます。 リクエストがまだ処理中の間に関数が再び呼び出されると、別の実行環境や別のインスタンスが準備され、関数の同時実行性が向上します。関数コードの実行が終了すると、他の要求を処理できるようになります。このプロセスは、後続のリクエストが届くたびに続き、実行環境が利用可能な場合は、それを再利用し、より多くの並行性が必要な場合は新しい実行環境を作成します。 並行性は、1つの実行環境で発生する同時または並列のリクエストおよび呼び出しの数としてカウントできます。同時リクエスト数は常に1です。ここでは、コールドスタートとウォームスタートが実行環境の実行数と常に等しい同時実行数で発生するときに、その変動がどのようになるかを確認できます。また、すべての関数または個別の関数に対して、CloudWatchの同時実行メトリクスを使用して同時実行数を表示することができます。

11 1 秒あたりのトランザクションについて [36:05]

では、1 秒あたりのトランザクション数と同時実行性はどのように関係しているのでしょうか。1 秒あたりのトランザクション数は、その期間中に行われるすべての呼び出しの合計です。例えば、関数の実行に1秒かかり、同時に10回の呼び出しが発生する場合、Lambdaは10の実行環境を作成し、この場合、1秒あたり10のリクエストを処理します。関数の期間が500ミリ秒に短縮された場合でも、Lambdaの同時実行数は10のままで、リクエストを処理する実行環境は依然として10あります。ただし、これらは1秒以内に再利用され、1秒あたりのトランザクション数は20になります。 特定の関数に対して最大同時実行数を設定することができます。これにより、同時に実行できる関数へのリクエストの最大数が制限され、アカウントの同時実行クォータから特定の関数の同時実行が予約されます。これにより、短い取引に対応できる一方で、関数が常に予約同時実行数の値までスケールアップできることを保証します。さらに、ダウンストリームリソースを保護するために、制限を設けたり、最大同時実行数を設定したりできます。 たとえば、データベースや外部APIが50の同時接続しか処理できない場合でも、50を超える同時呼び出しをスケーリングできず、ダウンストリームサービスを圧倒しないようにすることができます。また、関数の同時実行数を0に設定することもできます。これにより、基本的に呼び出しが停止します。さらに、ダウンストリームサービスに問題がある場合、この機能を使用してLambda処理を一時停止することができます。これにより、Lambdaを再度アクティブ化する前に、問題を修正するための時間を与えることができます。

12 プロビジョニングされた同時実行 [37:39]

もう 1 つの制御は、プロビジョニングされた同時実行です。 関数の公開バージョンに対して使用可能な実行環境の最小数を設定できます。 これにより、関数を事前にウォームアップし、事前にコールドスタートプロセスを実行しています。

これは、大量の同期リクエストが発生する予想されるトラフィックの急増に対応できるように、十分な数のLambda環境を確保することができます。例えば、 大規模セールや、 午後9時にテレビ番組をストリーミングするシーンなどが挙げられます。 プロビジョニングされた同時実行は、場合によってはコストを節約することができますが、バースト同時実行クォータやアカウント同時実行クォータなど、留意すべきクォータも存在します。バースト同時実行クォータは、各関数のトラフィックの初期バーストを提供し、リージョンによって1分あたり500から1000の範囲です。その後、関数は1分あたりさらに500インスタンスずつ拡張できます。また、特定のリージョンの最大同時実行数であるアカウント同時実行クォータも存在し、そのリージョンのアカウントのすべての関数で共有されます。デフォルトでは1000ですが、かなり大きな値に簡単に引き上げることができます。 コールドスタートの最適化や Graviton2 で関数を実行することによるコスト節約やパフォーマンス向上が図れます。また、関数のパワーレバーとしてメモリを使用することで、CPUとネットワーク帯域が追加されます。

ここでは、最適化のためにさまざまなメモリ割り当てを測定する方法、関数を VPC に接続する必要があるかどうか、 必要なときに正確に Lambda をスケーリングできるように同時実行とクォータがどのように機能するかについて詳しく説明しました。

次に「Configuration as Code」（コードとしての構成）は、 インフラストラクチャ・コードを使用して、サーバーレス アプリケーションを開発およびデプロイする際に、素晴らしい能力を提供することです。

インフラストラクチャコードは、アプリケーションリソースの定義や構成ファイルを使ったインフラストラクチャ設定ができる手法で、 構成ファイルをソフトウェアコードとして扱うことができます。 これにより、Gitリポジトリで追跡できるようになり、バージョン管理やプルリクエスト、レビューなどが可能になります。

プロビジョニングプロセスの自動化により、堅牢で反復可能なデプロイが実現できます。

インフラストラクチャコードを利用することで、構成のドリフトを取り除き、アプリケーションを複数の環境やアカウントにデプロイすることが容易になります。クラウドリソースを定義するためには多数のインフラストラクチャコードツールが利用できます。AWSからは、オープンソースフレームワークであるサーバレスアプリケーションモデル（SAM）や、クラウド開発キット（CDK）が提供されています。

これらのツールはいずれも、CloudFormationを生成するための構文を拡張します。 SAMはCloudFormationを生成する変換コンポーネントと、様々な開発・デプロイに役立つCLIツールの2つの部分からなります。 わずか20行のコードで関連するリソースを生成することができます。 ただし、セキュリティのためにも過度に寛容なポリシーは避けるべきです。IAM Access Analyzer を使用してポリシーを検証できるようになりました。 これに加えて、適切な最小特権のアクセス許可を使用してアプリケーションをより安全にするために、SAMポリシーテンプレートが利用可能です。

最近のSAMリリースでは、リソースを相互に接続するためのCloudFormationリソースであるSAM Connectorが発表されました。 これにより、Lambda 以外のリソースも容易に接続できます。 また、これによりリソースに適切な許可が与えられるかどうかを容易に判断できます。 テンプレート内でリソースの命名をハードコードせず、SAMに任せることで、テンプレートの再利用が容易になります。

また、SAM Delete を利用することで、コマンドラインからすべてのリソースを直接削除できます。

そして、既存のアプリケーション構築時に、ゼロから始める必要はありません。 Serverless Patterns Collectionは、豊富なサンプルコード・パターンを提供しており、これを利用することができます。 これらのパターンは、API Gateway や Lambda などを使用する際に非常に役立ちます。 さらに、AppSync、Cognito、Kinesis、EventBridge などを利用する際にも有用です。 既存のパターンをコピーして独自のものを使用したり、自分でパターンを追加することで、他のサーバーレス開発者を支援できます。

13 コードとしての構成: ベストプラクティス [46:39]

コードとしての構成を考える際には、フレームワークを使うことで多くのメリットが得られます。プログラムでインフラストラクチャを作成し、そのテンプレートをリポジトリに保存して再利用できるようにします。ポリシーテンプレートや SAM Connector を使用し、より良いセキュリティを確保し、サーバレスパターンコレクションの作成を開始します。 開発者は、様々なワークフローを使用して、コードを記述し、保存し、実行し、結果を確認することができます。

これはインナーループと呼ばれ、アプリケーションの構築中に素早いフィードバックを得るために役立ちます。 クラウドアプリケーションやサービスアプリケーションを構築する際には、開発中のコードだけでなく、他のサービスとのやり取りも考慮する必要があります。 現実的には、ローカルでテストするよりも、実際の環境でテストすることが重要です。

ローカルラップトップでこれらのサービスをエミュレートしたいと思っても、難しい場合があります。 エミュレーターの管理に多くの時間が割かれることもあります。しかし、機能するWebアプリのエミュレーターは価値があります。 ビジネスロジックをローカルで繰り返し処理し、できるだけ早く実際のクラウド環境でコードを実行する必要があります。 Lambda や API Gateway をローカルで迅速にテストしてから、クラウド内の実際のサービスと通信することができます。 クラウドで統合テストを実行することも重要です。 SAMチームは、この問題を解決するために SAM Accelerate を発表しました。

開発中は、ローカル開発のスピードでクラウドに対して反復処理を行うことができます。

SAM Sync により、ローカルのテンプレートファイル、テンプレート、ファイルコードを監視し、再構築されたものだけを再構築し、変更されたものを同期するだけで済みます。 クラウド内の変更がクラウドにすばやく同期され、これは非常に速いです。

SAM logs は、複数のログストリームとトレースからの集約されたフィードバックを端末に直接提供します。 これにより、ローカルでの高速テストが可能になります。 この方法により、クラウドでサーバーレスアプリケーションを開発する際に、高速なローカル開発エクスペリエンスと実際のクラウドリソースの使用という両方の長所が得られます。 これは、サーバーレスアプリケーションを構築するためのお決まりの方法であり、ぜひ試してみることをお勧めします。

14 再利用可能なテンプレート [50:29]

インフラストラクチャのコードテンプレートを使って、アプリの複数のコピーをデプロイできるようにすることが目的です。 開発者に独自のアカウントを与えることで、自分の開発サンドボックスを持つことができます。 また、開発、UATステージング、本番などの環境にも独自のアカウントが必要です。これによりワークロードの分離が可能で、セキュリティが向上し、本番データを保護できます。 テンプレートを再利用して複数の環境やアカウントにデプロイすれば、より一貫性が保たれます。 構成を外部のParameter Storeに保存し、他のテンプレートで参照することで一貫性を確保できます。しかし、アカウントの管理も必要です。 AWS Organization はアカウント作成を整理するのに役立ちますが、場合によっては複数のアカウントを持てない場合や開発者が複数のアカウントを持つ準備ができていない場合があります。そのため、共有アカウントとプレフィックスリソースを使用して簡単にデプロイできるようにしながら、一意にすることができます。 インフラストラクチャコードの強力な機能の一つは、自動化されたCI/CDパイプラインを設定することです。

これにより、再利用可能なテンプレートを使用して繰り返しデプロイできます。特にサーバーレスアプリ向けに、小さなコンポーネントや機能を構築する場合は、そのアジリティ（俊敏性）が得られます。その後、複数の配信パイプラインを構築できます。 また、SAM CLI を使用することで、コードリポジトリから複数のアカウントにアプリ・アーティファクトをデプロイするためのリソースとアクセス許可を安全に作成できます。CDKユーザーの場合、CDK Pipelinesが AWS Code Pipeline を使用してCI/CDパイプラインをセットアップするためのコンストラクトライブラリです。 本番環境でのテストやオブザーバビリティ主導の開発を取り入れることで、トラフィックのサブセットにデプロイし、以前のバージョンと比較する方法を確認できます。これにより、非常に安全に実験を行うことができます。また、インフラストラクチャコードの強力な機能をフル活用して、ログ分析やメトリクス作成を自動化し、視覚化することができます。 さらに、Lambda Power Tools を使えば、ロギング、トレース、メトリクスをLambda関数に簡単に追加できます。これらのツールは、コードの一部としてインポートするか、Lambdaレイヤーとして追加できます。また、AWSクラウドでは、合成テストが役立ちます。カナリアテストは、監視可能性を高めるためのガードレールを使用する優れた方法です。 最後に、サービスアプリケーションのオブザーバビリティを向上させるために、8部構成のラーニングパスビデオシリーズが利用できます。オブザーバビリティ駆動型開発は、コードのライフサイクル全体に関するもので、サービスがどのように実行されるか、およびすべての変更がビジネスに与える影響についての質問に答えることができます。特にサーバーイベント駆動型アプリケーションでは、優れたオブザーバビリティが非常に重要です。

15 One observability workshop [57:18]

One observability workshop では、オブザーバビリティに関する新しい実践的なトピックが取り上げられています。サーバーレスとオブザーバビリティの両方に関連する内容で、プロトタイプから本番環境への移行を円滑に進めることが目的です。 このワークショップでは、SAM Accelerate を使い、クラウドの力を活用してローカルで迅速に開発およびテストを行います。再利用可能なテンプレートや分離されたスタック、CI/CDパイプラインを活用してインフラストラクチャコードを効果的に扱っていきます。 ログ保持の構成についても、不要なログが保存されないよう、テンプレートを利用し設定を最適化します。

まとめ

Lambda Power Tools についても紹介し、開発効率の向上が期待できます。 イベントの力を用いて、サービス統合と Lambda の機能をフル活用し、状態の維持をより効果的に行う方法も紹介しました。また、インフラストラクチャをコードとして扱うことで、プロトタイプから本番環境への移行を円滑に進めることができます。 本ワークショップでは、すべてのベストプラクティスや最適化がカバーできないため、リンクリソースページを活用することが推奨されています。 これにより、サーバーレスアプリケーションをより効率的に構築できます。 さらに、AWSサーバーレスの学習を深めるために、自分のペースで情報収集しながら、サーバーレスバッジを獲得することができます。 また、一般的なサーバーレス情報を得るには、serverlessland.com が利用可能です。こちらには、AWSでのサーバーレスに関する多くのリソースが揃っています。

専門家が使うベストプラクティスを活用し、サーバーレス技術をさらに効果的に活用することが期待されています。このような深い技術的コンテンツを評価していただくことで、今後の進歩が見込まれます。

本セッションの内容に興味を持たれた方は、上部のリンクからセッション動画、セッション資料をご覧ください。